feat: Vaadin command interceptor #17738
Conversation
VaadinFilter simulates an around aspect around processing of a request related to vaadingh-17436
* renamed VaadinFilter to VaadinRequestInterceptor * Vaadin uses Lookup to init the VaadinService ** Added VaadinRequestInterceptors to ServiceInitEvent ** Added a VaadinRequestInterceptorServiceInitListener that will add interceptors to the init event ** The listener works with ServiceLocator based DI and Spring based DI (has both arg and non-arg constructor) ** That way we have 1 way of initializing the interceptors * Added the VaadinRequestInterceptorServiceInitListener to META-INF for automated locator discovery * Added the VaadinRequestInterceptorServiceInitListener as a bean for Spring Boot auto configuration * Extended the Instantiator mechanism to find all instances of a given class ** Implemented the method in Spring and non-Spring implementations
Co-authored-by: Mikhail Shabarov <61410877+mshabarov@users.noreply.github.com>
mshabarov
added
the
Contribution
| @@ -31,6 +34,9 @@ | |||
| public class FutureAccess extends FutureTask<Void> { | |||
| private final VaadinSession session; | |||
| private final Command command; | |||
| private final Iterable<VaadinCommandInterceptor> interceptors; | |||
| private final Map<Object, Object> context = new HashMap<>(); // TODO: | |||
There was a problem hiding this comment.
When FutureAccess objects are invoked, the session to which they belong is locked. The lifespan of context is scoped to a single FutureAccess object. Thus, I think there is no need to make this collection concurrent, because looks like only one thread invokes run, handleError and get method at any point in time.
| @@ -31,6 +34,9 @@ | |||
| public class FutureAccess extends FutureTask<Void> { | |||
| private final VaadinSession session; | |||
| private final Command command; | |||
| private final Iterable<VaadinCommandInterceptor> interceptors; | |||
| private final Map<Object, Object> context = new HashMap<>(); // TODO: | |||
There was a problem hiding this comment.
Do you have any examples of what can be shared between interceptors via this context?
| * @param command | ||
| * command | ||
| */ | ||
| void commandExecutionStart(Map<Object, Object> context, Command command); |
There was a problem hiding this comment.
How Command object would help developers? It's just a callback that give no information.
I'd rather pass to these methods something meaningful like session ID or any other information that helps to identify the command from another side rather than callback.
There was a problem hiding this comment.
I propose to pass the whole VaadinSession object as a parameter instead of Command.
| import java.util.Map; | ||
|
|
||
| /** | ||
| * Used to provide an around-like aspect option around command processing. |
There was a problem hiding this comment.
| * Used to provide an around-like aspect option around command processing. | |
| * Used to provide an around-like aspect option around processing of a {@link Command} submitted using {@link VaadinSession#access(Command)}. |
| @@ -352,6 +363,22 @@ protected List<VaadinRequestInterceptor> createVaadinRequestInterceptors() | |||
| return new ArrayList<>(); | |||
| } | |||
|
|
|||
| /** | |||
| * Called during initialization to add the request handlers for the service. | |||
There was a problem hiding this comment.
Should say "command interceptors", not "request interceptors"
| @@ -35,6 +38,12 @@ static class TestConfig { | |||
| MyRequestInterceptor myFilter() { | |||
| return new MyRequestInterceptor(); | |||
| } | |||
|
|
|||
| @Bean | |||
| MyVaadinComandInterceptor myVaadinComandInterceptor() { | |||
There was a problem hiding this comment.
This needs a counterpart in test, where this interceptor is asserted to be invoked.
No description provided.